Insertion of management agents during machine deployment

ABSTRACT

An invention is disclosed for configuring a VM of a deployment to be managed by a management system. In an embodiment, a deployment manager of a deployment instructs a host to create a VM. The VM is created with a base management agent that exposes interfaces to the management system that enable the management system to install management agents on the VM. The deployment manager installs a management agent that corresponds to a management system on the VM, and registers the VM with the management system. The management system may then manage the VM by communicating with the installed management agent on the VM.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.12/941,898, filed on Nov. 8, 2010, titled “Insertion of ManagementAgents During Machine Deployment,” the contents of which areincorporated by reference.

BACKGROUND

There are collections of multiple computers, commonly referred to asdata centers, server farms, or deployments. It is common in thesedeployments to have one or more management systems that monitor andmanage multiple computers (either physical computers or virtual machines(VMs)) in a deployment. For instance, a management system may managepatching the computers, standing up a computer—including installingapplications on the computer, and instantiating those applications (suchas a MICROSOFT Server App-V application virtualization package, or aMICROSOFT Database Application Components description of a database)—ormonitoring the health of the computers. Such a management system maymanage a computer by interacting with a corresponding management agenton the computer.

Furthermore, it is common for multiple computers of a deployment to behomogenously configured. Computers may be homogenously configured, forinstance, where they are configured to execute the same version of anoperating system, or they are configured to execute the same versions ofapplications.

One way that administrators configure computers to be managed bymanagement programs is as follows. An administrator orders thecomputers, receives them, mounts them in racks, installs program code oneach from a disc, and then registers each computer with one or moremanagement systems that will manage the computer. Apart from some of thedetails involving the physical machines themselves, an administrator mayconfigure the VMs in a deployment to be managed by management programsin a similar way. There are many problems with these known techniquesfor configuring VMs in a deployment to be managed by managementprograms, some of which are well known.

SUMMARY

It would therefore be an improvement for configuring VMs of a deploymentto be managed by management programs.

Including a management agent in an operating system gold image may bedesirable (sometimes referred to as baking the management agent into thegold image), but baking the agent in carries with it problems. There maybe many management agents, and anytime any agent changes, a new goldimage needs to be created, which takes work by an administrator.Additionally, some management agents are not designed to be baked in. Tobe baked in successfully, a management agent needs to be able to survivebeing generalized (most gold images do not contain machine-specificinformation, like a machine name, or an IP address of the machine),and/or a system preparation process (such as MICROSOFT Sysprep). Amanagement agent may not survive either of these processes, forinstance, because it relies on information changed by one of theseprocesses to be known and consistent.

Furthermore, it may be that a management agent cannot be configuredremotely, because the agent lacks exposed interfaces that enable aremote system to configure the agent. So, where an administrator maystand up dozens or hundreds of VMs in a few minutes, he or she wouldstill have to go in and manually configure each one of those VMs withthe management agent. Even where a management agent does have exposedinterfaces that allow for remote configuration, doing so may take anunacceptably long amount of time. It is typical to address computersusing the Domain Name System (DNS). However, once a computer is broughtonline and registered with DNS, it may take several minutes for the DNSregistration to propagate through a communications network so that thecomputer can be remotely addressed via DNS. This time required for a DNSname to propagate may be unacceptably long.

Therefore, it may be advantageous to install a management program in aVM separate from imaging the VM with a gold image. In an embodiment, adeployment has a deployment manager that is configured to create,destroy and manage VMs on hosts in the deployment. An example of such adeployment manager is MICROSOFT's System Center Virtual Machine Manager(SCVMM). The deployment manager determines that a VM is to be created ona host, and instructs that host to create a VM. When the deploymentmanager receives and indication that the VM has been created, thedeployment manager instructs the VM to install a management agent ormanagement program, that a management system may communicate with tomanage the VM. The management agent provided functionality for themanagement system to manage the computer. For instance, the managementagent may expose interfaces that allow the management system tocommunicate with the management agent, and the management agent maycarry out on the computer actions to effectuate the instructions of themanagement system. The deployment manager also registers the VM with themanagement system. The management system may then manage the VM bycommunicating with the management agent on the VM.

Other embodiments of an invention for configuring VMs of a deployment tobe managed by management programs, exist, and some examples of such aredescribed with respect to the detailed description of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The systems, methods, and computer-readable media for configuring a VMof a deployment to be managed by a management system are furtherdescribed with reference to the accompanying drawings in which:

FIG. 1 depicts an example general purpose computing environment in whichan aspect of an embodiment of the invention can be implemented .

FIG. 2 depicts an example virtual machine host wherein an aspect of anembodiment of the invention can be implemented.

FIG. 3 depicts a second example virtual machine host wherein an aspectof an embodiment of the present invention can be implemented.

FIG. 4 depicts an example system architecture for configuring a VM of adeployment to be managed by a management system.

FIG. 5 depicts another example system architecture for configuring a VMof a deployment to be managed by a management system.

FIG. 6 depicts an example system architecture for configuring a VM of adeployment to be managed by multiple management systems.

FIG. 7 depicts an example system architecture for configuring multipleVMs of a deployment to be managed by a management system.

FIG. 8 depicts example operational procedures for a system thatconfigures a VM of a deployment to be managed by a management system.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Embodiments may execute on one or more computer systems. FIG. 1 and thefollowing discussion are intended to provide a brief general descriptionof a suitable computing environment in which the disclosed subjectmatter may be implemented.

The term processor used throughout the description can include hardwarecomponents such as hardware interrupt controllers, network adaptors,graphics processors, hardware based video/audio codecs, and the firmwareused to operate such hardware. The term processor can also includemicroprocessors, application specific integrated circuits, and/or one ormore logical processors, e.g., one or more cores of a multi-core generalprocessing unit configured by instructions read from firmware and/orsoftware. Logical processor(s) can be configured by instructionsembodying logic operable to perform function(s) that are loaded frommemory, e.g., RAM, ROM, firmware, and/or mass storage.

Referring now to FIG. 1, an exemplary general purpose computing systemis depicted. The general purpose computing system can include aconventional computer 20 or the like, including at least one processoror processing unit 21, a system memory 22, and a system bus 23 thatcommunicative couples various system components including the systemmemory to the processing unit 21 when the system is in an operationalstate. The system bus 23 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. The system memorycan include read only memory (ROM) 24 and random access memory (RAM) 25.A basic input/output system 26 (BIOS), containing the basic routinesthat help to transfer information between elements within the computer20, such as during start up, is stored in ROM 24. The computer 20 mayfurther include a hard disk drive 27 for reading from and writing to ahard disk (not shown), a magnetic disk drive 28 for reading from orwriting to a removable magnetic disk 29, and an optical disk drive 30for reading from or writing to a removable optical disk 31 such as a CDROM or other optical media. The hard disk drive 27, magnetic disk drive28, and optical disk drive 30 are shown as connected to the system bus23 by a hard disk drive interface 32, a magnetic disk drive interface33, and an optical drive interface 34, respectively. The drives andtheir associated computer readable media provide non volatile storage ofcomputer readable instructions, data structures, program modules andother data for the computer 20. Although the exemplary environmentdescribed herein employs a hard disk, a removable magnetic disk 29 and aremovable optical disk 31, it should be appreciated by those skilled inthe art that other types of computer readable media which can store datathat is accessible by a computer, such as flash memory cards, digitalvideo disks, random access memories (RAMs), read only memories (ROMs)and the like may also be used in the exemplary operating environment.Generally, such computer readable storage media can be used in someembodiments to store processor executable instructions embodying aspectsof the present disclosure.

A number of program modules comprising computer-readable instructionsmay be stored on computer-readable media such as the hard disk, magneticdisk 29, optical disk 31, ROM 24 or RAM 25, including an operatingsystem 35, one or more application programs 36, other program modules 37and program data 38. Upon execution by the processing unit, thecomputer-readable instructions cause the actions described in moredetail below to be carried out or cause the various program modules tobe instantiated. A user may enter commands and information into thecomputer 20 through input devices such as a keyboard 40 and pointingdevice 42. Other input devices (not shown) may include a microphone,joystick, game pad, satellite dish, scanner or the like. These and otherinput devices are often connected to the processing unit 21 through aserial port interface 46 that is coupled to the system bus, but may beconnected by other interfaces, such as a parallel port, game port oruniversal serial bus (USB). A monitor 47, display or other type ofdisplay device can also be connected to the system bus 23 via aninterface, such as a video adapter 48. In addition to the display 47,computers typically include other peripheral output devices (not shown),such as speakers and printers. The exemplary system of FIG. 1 alsoincludes a host adapter 55, Small Computer System Interface (SCSI) bus56, and an external storage device 62 connected to the SCSI bus 56.

The computer 20 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer49. The remote computer 49 may be another computer, a server, a router,a network PC, a peer device or other common network node, and typicallycan include many or all of the elements described above relative to thecomputer 20, although only a memory storage device 50 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1 caninclude a local area network (LAN) 51 and a wide area network (WAN) 52.Such networking environments are commonplace in offices, enterprise widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 20 can beconnected to the LAN 51 through a network interface or adapter 53. Whenused in a WAN networking environment, the computer 20 can typicallyinclude a modem 54 or other means for establishing communications overthe wide area network 52, such as the Internet. The modem 54, which maybe internal or external, can be connected to the system bus 23 via theserial port interface 46. In a networked environment, program modulesdepicted relative to the computer 20, or portions thereof, may be storedin the remote memory storage device. It will be appreciated that thenetwork connections shown are exemplary and other means of establishinga communications link between the computers may be used. Moreover, whileit is envisioned that numerous embodiments of the present disclosure areparticularly well-suited for computerized systems, nothing in thisdocument is intended to limit the disclosure to such embodiments.

System memory 22 of computer 20 may comprise instructions that, uponexecution by computer 20, cause the computer 20 to implement theinvention, such as the operational procedures of FIG. 8.

FIG. 2 depicts an example VMHost virtual machine host (sometimesreferred to as a VMHost or host) wherein an aspect of an embodiment ofthe invention can be implemented. The VMHost can be implemented on acomputer such as computer 20 depicted in FIG. 1, and VMs on the VMHostmay execute an operating system that effectuates a remote presentationsession server. As depicted, computer system 200 comprises logicalprocessor 202 (an abstraction of one or more physical processors orprocessor cores, the processing resources of which are made available toapplications of computer system 200), RAM 204, storage device 206, GPU212, and NIC 214.

Hypervisor microkernel 202 can enforce partitioning by restricting aguest operating system's view of system memory. Guest memory is apartition's view of memory that is controlled by a hypervisor. The guestphysical address can be backed by system physical address (SPA), i.e.,the memory of the physical computer system, managed by hypervisor. In anembodiment, the GPAs and SPAs can be arranged into memory blocks, i.e.,one or more pages of memory. When a guest writes to a block using itspage table, the data is actually stored in a block with a differentsystem address according to the system wide page table used byhypervisor.

In the depicted example, parent partition component 204, which can alsobe also thought of as similar to “domain 0” in some hypervisorimplementations, can interact with hypervisor microkernel 202 to providea virtualization layer. Parent partition 204 in this operationalenvironment can be configured to provide resources to guest operatingsystems executing in the child partitions 1-N by using virtualizationservice providers 228 (VSPs) that are sometimes referred to as “back-enddrivers.” Broadly, VSPs 228 can be used to multiplex the interfaces tothe hardware resources by way of virtualization service clients (VSCs)(sometimes referred to as “front-end drivers”) and communicate with thevirtualization service clients via communication protocols. As shown bythe figures, virtualization service clients can execute within thecontext of guest operating systems. These drivers are different than therest of the drivers in the guest in that they may be supplied with ahypervisor, not with a guest.

Emulators 234 (e.g., virtualized integrated drive electronics device(IDE devices), virtualized video adaptors, virtualized NICs, etc.) canbe configured to run within the parent partition 204 and are attached toresources available to guest operating systems 220 and 222. For example,when a guest OS touches a register of a virtual device or memory mappedto the virtual device 202, microkernel hypervisor can intercept therequest and pass the values the guest attempted to write to anassociated emulator.

Each child partition can include one or more virtual processors (230 and232) that guest operating systems (220 and 222) can manage and schedulethreads to execute thereon. Generally, the virtual processors areexecutable instructions and associated state information that provide arepresentation of a physical processor with a specific architecture. Forexample, one virtual machine may have a virtual processor havingcharacteristics of an INTEL x86 processor, whereas another virtualprocessor may have the characteristics of a PowerPC processor. Thevirtual processors in this example can be mapped to logical processorsof the computer system such that the instructions that effectuate thevirtual processors will be backed by logical processors. Thus, in anembodiment including multiple logical processors, virtual processors canbe simultaneously executed by logical processors while, for example,other logical processors execute hypervisor instructions. Thecombination of virtual processors and memory in a partition can beconsidered a virtual machine.

Guest operating systems can include any operating system such as, forexample, a MICROSOFT WINDOWS operating system. The guest operatingsystems can include user/kernel modes of operation and can have kernelsthat can include schedulers, memory managers, etc. Generally speaking,kernel mode can include an execution mode in a logical processor thatgrants access to at least privileged processor instructions. Each guestoperating system can have associated file systems that can haveapplications stored thereon such as terminal servers, e-commerceservers, email servers, etc., and the guest operating systemsthemselves. The guest operating systems can schedule threads to executeon the virtual processors and instances of such applications can beeffectuated.

FIG. 3 depicts a second example VMHost wherein an aspect of anembodiment of the present invention can be implemented. FIG. 3 depictssimilar components to those of FIG. 2; however in this exampleembodiment the hypervisor 238 can include the microkernel component andcomponents from the parent partition 204 of FIG. 2 such as thevirtualization service providers 228 and device drivers 224 whilemanagement operating system 236 may contain, for example, configurationutilities used to configure hypervisor 204. In this architecturehypervisor 238 can perform the same or similar functions as hypervisormicrokernel 202 of FIG. 2; however, in this architecture hypervisor 234can be configured to provide resources to guest operating systemsexecuting in the child partitions. Hypervisor 238 of FIG. 3 can be astand alone software product, a part of an operating system, embeddedwithin firmware of the motherboard or a portion of hypervisor 238 can beeffectuated by specialized integrated circuits.

FIG. 4 depicts an example system architecture for configuring VMs of adeployment to be managed by a management system, such as VMs executingon the VMHost depicted in FIG. 2 or 3. Deployment 300 comprisesdeployment manager 302, host 304 and management system 312. In turn,host 304 comprises hypervisor 306, VM-1 308-1 through VM-N 308-N, andVHD-1 310-1 (virtual hard drive) through VHD-N 310-N. Deployment manager302 is configured to manage deployment 300. Among other functions,deployment manager may instruct a host 304 to create or destroy a VM308, may provision a VM 308, may migrate a VM 308 between hosts 304 (asdepicted, deployment 300 has one host 304, but it may comprise multiplehosts 304). As depicted in FIG. 4 and elsewhere, depicted elements (suchas deployment manager 302 and management system 312) may execute onseparate physical computers, or share a physical computer with anotherdepicted element—such as each executing in separate VMs on the physicalcomputer, or even within the same VM on the physical computer.

Host 304 may comprise more or fewer than two VMs 308, though two aredepicted. Likewise, host 304 may comprise more or fewer than two VHDs310, though two are depicted. As depicted, each VHD 310 is associatedwith a VM 308—the VM 308 mounts the VHD 310 and may both read data fromit and write data to it. A VM 308 may have more than one VHD 310associated with it. Furthermore, a VHD 310 need not be stored on host304, but may be stored elsewhere on a communication network, andassociated with the VM 308 across the communication network. Host 304also comprises hypervisor 306, which manages VMs 308, includingpresenting VMs with virtual hardware resources.

Management system 312 is configured to manage one or more aspects of oneor more VMs 308. For instance, management system 312 may be configuredto ensure that a VM 308 is properly updated by deploying patches to VM308. Management system 312 may also be configured to manage the healthof VM 308, such as by ensuring that it is running in an allowable state(including whether certain processes are running, certain files arepresent, or that there are no entries in an error log indicating that anerror is present in a particular subsystem). Management system 312 mayeffectuate this management of a VM 308 by communicating with amanagement agent that executes on VM 308.

The following communication flow within deployment 300 may be used toeffectuate configuring a VM of deployment 300 to be managed bymanagement system 312. In communication (1), deployment manager 302sends an instruction to hypervisor 306 to create VM-1 308-1. Hypervisor306 may create VM-1 308-1 with various parameters (e.g., amount and typeof central processing units, amount and type of system memory, numberand type of storage devices), and then associate VHD-1 310-1 with VM308-1, such that VM-1 308-1 mounts VHD 310-1. Deployment manager 302 maycreate VM-1 308-1 with an image file (sometimes referred to as a goldimage, or a golden image) that comprises aspects of the VM-1 308-1, suchas data for a guest operating system (guest OS).

Upon creation of VM-1 308-1, deployment manager 302 receivesacknowledgement that VM-1 308-1 has been created. Hypervisor 306 maysend deployment manager 302 an indication that it has successfullycreated VM-1 308-1, or VM-1 308-1 itself may communicate with deploymentmanager 302 to convey this information that it has been created. Whendeployment manager 302 has determined that VM-1 308-1 has been created,in communication (2), deployment manager 302 installs a management agentfor management system 312. VM-1 308-1 may have been created with a basemanagement agent—a process that executes within VM-1 308-1 that exposesan interface that enables deployment manager 302 to install othermanagement agents on VM-1 308-1. Where this is the case, deploymentmanager 302 may instruct the base management agent on VM-1 308-1 toinstall a management agent for management system 312. Deployment manager302 may, for instance, send VM-1 308-1 a copy of the management agent,send VM-1 308-1 a link to a location from where the management agent maybe obtained, or direct VM-1 308-1 to a location in a file system of VM-1308-1 where the management agent is installed. Once VM-1 308-1 has themanagement agent itself, VM-1 308-1 may undertake an installationprocedure to install the management agent, so it is configured tocommunicate with management system 312. After the management agent hasbeen installed, VM-1 308-1 may communicate this fact to deploymentmanager 302.

After deployment manager 302 determines that the management agent hasbeen installed on VM-1 308-1, deployment manager 302 may communicate (3)with management system 312 to register the management agent withmanagement system 312. This act of registration may include anindication to create an account or other entry for VM-1 308-1 onmanagement system 312, and also an indication of how to reach themanagement agent of VM-1 308-1, such as an IP address of VM-1 308-1, anda port upon which the management agent listens.

After the management agent of VM-1 308-1 has been registered withmanagement system 312, management system 312 may manage VM-1 308-1. Incommunication (4), management system 312 performs such management ofVM-1 308-1. For instance, communication (4) may comprise managementsystem 312 sending the management agent of VM-1 308-1 an indication ofan operating system patch that the management agent is to use to patch aguest operating system of VM-1 308-1.

It may be appreciated that there may be additional communication flowsin the process of configuring VMs of a deployment to be managed by amanagement system. For instance, communication (1)—which here depictsdeployment manager 302 instructing hypervisor 306 to create VM-1308-1—may involve more communications than just the depictedcommunication (1) from deployment manager 302 to hypervisor 306. Thiscommunication flow may include multiple communications from deploymentmanager 302 to hypervisor 306 and one or more communications fromhypervisor 306 to deployment manager 302.

FIG. 5 depicts another example system architecture for configuring a VMof a deployment to be managed by a management system, in addition to theexample system architecture depicted in FIG. 4. Deployment 300 b,deployment manager 302 b, host 304 b, hypervisor 306 b, VMs 308-1 bthrough 308-Nb, VHDs 310-1 b through 310-1Nb, and management system 312b may be similar to deployment 300, deployment manager 302, host 304,hypervisor 306, VMs 308-1 through 308-N, VHDs 310-1 through 310-1N, andmanagement system 312, respectively, of FIG. 4. Additionally,communication flows (1 b), (2 b), and (4 b) may be similar tocommunication flows (1), (2), and (4), respectively, of FIG. 4.

The primary difference between FIGS. 3A and 3B is in how the managementagent of VM-1 308-1 and VM-1 b 308-1 b register with respectivemanagement systems 312 and 312 b. In FIG. 4, deployment manager 302determines that VM-1 308-1 has installed the management agent, and thenregisters VM-1 308-1 with management system 312 in communication (3).Registering the management agent with management system 312 as in theembodiment of FIG. 4 may be preferable where deployment manager 302 alsoun-registers VMs 308 from management system 312, because then the actsof registering and un-registering are similar—both involve acommunication from deployment manager 302 to management system 312.

In contrast, the communication (3 b) of FIG. 5, where the managementagent of VM-1 b 308-1 b contacts may also be preferable under certaincircumstances. For instance, this may reduce the processing resourcesrequired by deployment manager 302, since deployment manager may haveless work to do, and may simply the communication flow, sincecommunication (3 b) is sent directly from VM-1 b 308-1 b to managementserver 312, as opposed to through deployment manager 302 b, as takesplace in FIG. 4.

FIG. 6 depicts an example system architecture for configuring a VM of adeployment to be managed by multiple management system, in addition tothe system architectures depicted in FIGS. 4 and 5.

Deployment 300 c, deployment manager 302 c, host 304 c, hypervisor 306c, VMs 308-1 c through 308-Nc, VHDs 310-1 c through 310-1Nc, andmanagement system 312 c may be similar to deployment 300, deploymentmanager 302, host 304, hypervisor 306, VMs 308-1 through 308-N, VHDs310-1 through 310-1N, and management system 312, respectively, of FIG.4. Also depicted is management server 312-2 c, which is similar tomanagement server 312 c, though may be responsible for a different typeof management (for instance, management system 312 c may be responsiblefor managing patching of VMs 308, while management system 312-2 c may beresponsible for managing the health of VMs 308).

Additionally, communication flows (1 c) and (2 c) may be similar tocommunication flows (1) and (2), respectively of FIG. 4. Communicationflows (3 c-1) and (3 c-2) may each be similar to communication flow (3)of FIG. 4, and communication flows (4 c-1) and (4 c-2) may each besimilar to communication flow (3) of FIG. 4.

FIG. 6 shows how multiple management systems 312 c may be used to managea single VM 308. In FIG. 6, communication flow (2 c) comprisesinstalling two management agents on VM-1 c 308-1 c—one management agentfor management server 312 c, and a second management agent formanagement server 312-2 c. After deployment manager 302 c has determinedthat the management agent corresponding to management system 312 c hasbeen installed on VM-1 c 308-1 c, deployment manager 302 c makescommunication (3-1 c) to management server 312 c to register VM-1 c308-1 c with management server 312 c. Likewise, after deployment manager302 c has determined that the management agent corresponding tomanagement system 312-2 c has been installed on VM-1 c 308-1 c,deployment manager 302 c makes communication (3-2 c) to managementserver 312-2 c to register VM-1 c 308-1 c with management server 312-2c.

When VM-1 c 308-1 c has been registered with each respective managementsystem 312, that management system 312 may then manage VM-1 c 308-1 c.Management system 312 c manages VM-1 c 308-1 c by communicating withVM-1 c 308-1 c in communication (4-1 c), and management system 312-2 cmanages VM-1 c 308-1 c by communicating with VM-1 c 308-1 c incommunication (4-2 c).

FIG. 7 depicts an example system architecture for configuring multipleVMs of a deployment to be managed by a management system, in addition tothe system architectures depicted in FIGS. 4-6.

Deployment 300 d, deployment manager 302 d, host 304 d, hypervisor 306d, VMs 308-1 d through 308-Nd, VHDs 310-1 d through 310-1Nd, andmanagement system 312 d may be similar to deployment 300, deploymentmanager 302, host 304, hypervisor 306, VMs 308-1 through 308-N, VHDs310-1 through 310-1N, and management system 312, respectively, of FIG.4. Similarly, each of communications (1-1 d) and (1-2 d) may be similarto communication (1) of FIG. 4; each of communications (2-1 d) and (2-2d) may be similar to communication (2) of FIG. 4; each of communications(3-1 d) and (3-2 d) may be similar to communication (3) of FIG. 4; andeach of communications (4-1 d) and (4-2 d) may be similar tocommunication (4) of FIG. 4.

It may be appreciated that multiple VMs—depicted herein as VM-1 d 308-1d and VM-Nd 308-Nd—may be registered with a single management system 312d, and that single management system 312 d may manage each of those VMs308-1 d and 308-Nd. Management system 312 d may send these VMs 308roughly similar management instructions. This may occur, for instance,where each VM 308 has the same version of a guest OS, so when managementsystem 312 d manages the VMs 308 by patching them, management system 312d instructs each VM 308 to install the same patch. Management system 312d may also send these VMs 308 management instructions that varysomewhat. This may occur, for instance, where management system 312 d ismanaging the health of VMs 308. Where VM-1 d 308-1 d is in a healthystate, and VM-Nd 308-Nd is in an unhealthy state, management system 312d may send to VM-Nd 308-Nd instructions related to diagnosing why VM-Nd308-Nd is in an unhealthy state. Management system 312 d may not sendthese instructions to VM-1 d 308-1 d because VM-1 d 308-1 d is in ahealthy state.

FIG. 8 depicts example operational procedures for a system thatconfigures a VM of a deployment to be managed by a management system.These operational procedures may be implemented in deployment manager302 of FIGS. 4-7 to implement the present invention

The operational procedures begin with operation 400, which leads intooperation 402. Operation 402 depicts instructing the first computer tocreate the VM. This operation may be performed by a deployment manager,such as deployment manager 302 of FIG. 4, and may be similar tocommunication (1) of FIG. 4, where the deployment manager 302 sends aninstruction to the hypervisor 306 of a host 304 to create a new VM—VM-1308-1.

Operation 404 depicts installing a management program corresponding tothe second computer on the VM. Operation 404 may be performed by adeployment manager that issues such an instruction to the VM, such asdeployment manager 302 of FIG. 4. Operation 404 may be similar tocommunication (2) of FIG. 4, where the deployment manager sends aninstruction to VM-1 308-1 to install a management agent upon VM-1 308-1that corresponds to management system 312.

The base management agent may expose an interface such as a MICROSOFTWindows Management Interface (WMI) interface. The deployment manager mayinstruct the base management agent through making a call to the exposedinterface of the VM to download or otherwise obtain files for amanagement agent that corresponds to the management system to a locationin a file system of the VM (such as ADMMIN$ in versions of the MICROSOFTWINDOWS operating system). The deployment manager may also make aninterface call to have the base management agent instruct an installerprogram (such as MICROSOFT Installer Package (MSI)) to install themanagement agent for the management system.

Operation 404 may also comprise copying the management program to avirtual hard drive (VHD) mounted by the VM. A way to install themanagement agent corresponding to the management system on the VM is tostore the management agent on a virtual hard disk (VHD) or other disk,and have the VM mount the VHD, and run an installer program for themanagement agent. This may be effectuated such as through an xcopy(extended copy) command.

Operation 404 may also comprise instructing the VM to mount an imagefile that stores the management program, the mounted image file beingpresented to the VM as removable media. For instance, the deploymentmanager may store the management agent in an image file (such as an ISOimage), and then instructing the VM to mount the image file as, forinstance, a DVD disc, and install the management agent from that mountedimage file.

In an embodiment where operation 404 comprises instructing the VM toinstall a management program corresponding to the second computer isperformed by a third computer—such as deployment manager 302—operation406 comprises: sending, by the third computer, to the second computer, amessage indicative of registration of the VM.

In an embodiment where the operational procedures of FIG. 8 includesending the VM configuration information for the management program,operation 404 comprises: instructing the VM to configure the managementprogram based on the configuration information. The configurationinformation may comprise information identifying the second computer,such as an IP address of the second computer. The information may alsocomprise a security secret used by the VM to communicate with the secondcomputer (such as to register the VM with the second computer, asdepicted in operation 406). The VM may use the security secret as proofto the second computer (which did not create the VM, and may not beaware of the VM prior to this act of registration) that the VM should beregistered with the second computer, rather than being, for instance, amalicious entity attempting to masquerade as an appropriate entity. Thesecret may, for instance, be a certificate issued by an authoritytrusted by the management system. Where both the VM and the secondcomputer possess the security secret, the VM may use the security secretas the input to a mathematical function, and send the result to thesecond computer. The second computer may also use the security secret asthe input to the same mathematical function, and compare the result itdetermines against the result received from the VM. Where the secondcomputer determines that the results match, it may determine that the VMpossesses the security secret, and therefore, may be registered with thesecond computer.

Operation 406 depicts registering the VM with the second computer, suchas management system 312 of FIG. 4. This act of registration may beperformed directly from the VM to the second computer—in an embodiment,operation 406 comprises sending, by the VM, to the second computer, amessage indicative of registration of the VM. This act of registrationmay be performed be an entity other than the VM—such as the deploymentmanager 302 of FIG. 4—in an embodiment where operation 404 is performedby a third computer, operation 406 comprises: sending, by the thirdcomputer, to the second computer, a message indicative of registrationof the VM. Operation 406 may be performed in a manner similar tocommunication flow (3) of FIG. 4.

Operation 408 depicts sending the VM an instruction indicative ofmanagement of the VM by the second computer. Operation 408 may beperformed in a manner similar to communication flow (4) of FIG. 4. Forinstance, where the second computer is responsible for patch management,operation 408 may comprise the second computer sending the VM aninstruction to download and install an operating system patch for aguest OS of the VM. The VM may initiate the management process. Forinstance, the agent may query the management system for a manifest ofrequired patches for the VM, then check the VM to see whether therequired patches are installed. If not, the agent may download andinstall those patches.

Operation 410 depicts installing a second management program on the VMcorresponding to a third computer—such as management system 312-2 c ofFIG. 6; registering the VM with the third computer; and sending the VMan instruction indicative of management of the VM by the third computer.A single VM may be managed by multiple management systems 312, and VM312 may have a separate management agent executing within it thatcorresponds to each management system 312. Thus, the second computer andthird computer may each have the VM registered to them, and may eachmanage the VM.

Operation 412 depicts instructing a third computer—such as anotherinstance of VM host 304 of FIG. 4 to create a second VM; installing themanagement program on the second VM; and sending the second VM aninstruction indicative of management of the second VM by the secondcomputer. One management system 312 may manage multiple VMs, even VMsthat execute on different hosts. Each of those VMs under management maybe registered to management system 312, and management system 312 maysend each management instructions, similar to communication flows (4-1d) and (4-2 d) of FIG. 7.

Operation 414 depicts determining that the VM is to be terminated;terminating the VM; and unregistering the VM with the second computer.Deployment manager 302 of FIG. 4 may control the act of terminating VMs.There may be times where a VM may be terminated or otherwise shut downin an orderly fashion, such as where the deployment manager 302determines that a VM has skewed too far from a known state. In such ascenario, deployment manager 302 of FIG. 4 may determine to terminatethe VM, and take actions to effectuate this. The deployment manager 302may also unregister the VM from the management system 312, so thatmanagement system 312 does not keep attempting to manage a VM that is nolonger executing.

Operation 416 depicts determining that the VM has terminated; andunregistering the VM with the second computer. The VM may also terminateunexpectedly—such as where there is a hardware failure of the host uponwhich it executes (like host 304 of FIG. 4) that causes the host, andall VMs executing on it, to shut down. An entity, such as deploymentmanager 302 of FIG. 4, may monitor the running status VMs of adeployment, and where it determines that a VM has terminated, notify thesecond computer of this to unregister it.

The operational procedures conclude with operation 418. It may beappreciated that not all operational procedures need be present in everyembodiment of the invention. For instance, an embodiment of theinvention may implement operations 400, 402, 404, 406, 408, and 418,where a VM is created, a management program is installed on the VM, theVM is registered with a management system, and the management systemsends an instruction to the VM indicative of management of the VM.

Conclusion

While the present invention has been described in connection with thepreferred aspects, as illustrated in the various figures, it isunderstood that other similar aspects may be used or modifications andadditions may be made to the described aspects for performing the samefunction of the present invention without deviating there from.Therefore, the present invention should not be limited to any singleaspect, but rather construed in breadth and scope in accordance with theappended claims. For example, the various procedures described hereinmay be implemented with hardware or software, or a combination of both.Thus, the methods and apparatus of the disclosed embodiments, or certainaspects or portions thereof, may take the form of program code (i.e.,instructions) embodied in tangible media, such as floppy diskettes,CD-ROMs, hard drives, or any other machine-readable storage medium. Whenthe program code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus configured for practicing thedisclosed embodiments. In addition to the specific implementationsexplicitly set forth herein, other aspects and implementations will beapparent to those skilled in the art from consideration of thespecification disclosed herein. It is intended that the specificationand illustrated implementations be considered as examples only.

What is claimed:
 1. A method for configuring a virtual machine (VM) of afirst computer to be managed by a second computer, comprising:instructing the first computer to create the VM; installing a managementprogram on the VM corresponding to the second computer; registering theVM with the second computer; and sending the VM an instructionindicative of management of the VM by the second computer.